fix(rbac): don't let namespaced roles grant cluster-scoped actions - #614

PR Checklist

• Linting Test is passing
• Code is well documented
• If applicable, a PR in the epinio/docs repository has been opened

epinio/docs#491

Summary

The dashboard showed Create/Edit/Delete buttons for cluster-scoped resources
(app charts, builder images, git configs, catalog services, namespace create)
to users who can't actually perform them. The clearest case is the default
epinio user: its admin:workspace role made the buttons appear, but the
server 403s the request.

Occurred changes and/or fixed issues

Root cause: buildPermissionsFromRoles flattened every role from /api/v1/me
into one permission map, ignoring role.namespace. A namespace-scoped admin
(admin:workspace) therefore granted cluster-scoped actions globally. The UI
now gates cluster-scoped writes against global (non-namespaced) roles only,
matching the server's User.IsAllowed. No server change.

Technical notes summary

• utils/permissions.ts: build a globalActions set (actions from
  namespace-less roles); override CLUSTER_SCOPED_ACTIONS
  (chart_write, builderimage_write, gitconfig_write) to
  globalActions.has(a). Catalog and namespace are mixed actions (only part is
  cluster-scoped), so derive catalog_service_write from global service_write
  and namespace_create from global namespace_write.
• list/catalogservices.vue: create/edit/delete gate now uses
  catalog_service_write (matches the detail view).
• list/namespaces.vue: split the create gate from delete; create uses global
  namespace_create, delete stays on namespace_write (per-namespace).

Areas or cases that should be tested

As default epinio user (user global + admin:workspace):

• App-chart, git-config, catalog-service Create buttons hidden.
• Builder-image Create still shown (global user role holds builderimage_write).
• Namespace Create hidden when the global role has only namespace_read;
  namespace Delete still shown for the admin'd namespace.
• App / configuration / service-instance Create still shown in that namespace.
  As a global admin: all Create buttons shown. As view_only: none.
  Sanity check: a direct POST /appcharts still returns 403 (UI now matches the
  server; server behavior is unchanged). Tested in ; reviewer please use
  a different one.

Areas which could experience regressions

All permission-gated Create/Edit/Delete buttons, since they share the
epinio/can getter. Most exposed: namespace delete (gate was split) and catalog
management (gate repointed). Server enforcement is unchanged, so the worst case
is a button shown/hidden mismatch, not an auth bypass. Global roles (admin,
application_manager, etc.) are unaffected, their actions are in globalActions.